The distributed nature of Active Directory necessitates data segregation. These partitions which organise various data are called Naming Contexts (NCs), also known as directory partitions. Active Directory comes with three types of predefined naming contexts:

• Domain Naming Context - for each domain in the forest;
• Configuration Naming Context - one per forest;
• Schema Naming Context - one per forest.

Additionally, administrators can define additional naming contexts for organising data by using Application Partitions.

Every domain in an Active Directory environment has a Domain Naming Context designed for storing data pertaining to that specific domain. The root of this directory partition is called the NC head and is represented by the domain's distinguished name (in this case dc=cybercorp,dc=com). Every domain controller in the domain maintains a copy of the domain's naming context.

The Configuration Naming Context stores configuration information about the entire forest and is located under the configuration container cn=Configuration,dc=<forest root domain>,dc=<forest root domain extension> (in the example case, cn=Configuration,dc=cybercorp,dc=com). The configuration partition is replicated to every domain controller inside the forest. Furthermore, writable domain controllers maintain a writable copy of it.

The Schema Naming Context contains the Schema of the Active Directory environment. Since there is a single schema for the entire forest, this partition is also replicated to every domain controller in the forest. It can be found under cn=Schema,Configuration,dc=<forest root domain>,dc=<forest root domain extension>.

Application partitions allow administrators to create custom data storage areas on domain controllers of their choice, rather than entire domains or the forest. One can easily define which domain controllers should maintain a replica of a given application partition because Active Directory automatically sets up the replication after the domain controllers are chosen.

Naming application partitions is similar to naming domains - for example, dc=apppartition,dc=cybercorp,dc=local. Furthermore, the location of an application partition is rather flexible. They can be positioned under domains, under other application partitions or they can be the root of an entirely new domain tree.

There are, however, certain limitations to the objects that an application partition may contain. Application partitions cannot store security principals and the objects within cannot be relocated outside the partition. Moreover, objects in an application partition are not tracked by the Global Catalog.